1. Field of the Invention
The present invention relates generally to systems and methods of non-synchronous communication and, particularly to a system and method for voice on demand elements of private message chats, where end users may elect the modality of their chat communication for each receipt of a message, and each response.
2. Description of the Prior Art
Traditional telephony allows a variety of calling paradigms including: one to one (regular call), one to many (party line on receiving side), and many to many (conference call). Each conversation traditionally requires a circuit, and the call flow follows the path of call request (dial), call setup, call accept (on the receiver side), cut through and conversation. When one party hangs up the call is terminated. Call setup often involves a long time, up to 30 seconds, and the nature of the telephone switch prevents rapid call termination/initiation. When one party hangs up and then attempts to reinitiate a call to the same number, the line is often still busy, and it is necessary to wait until it clears before completing the call.
Voice over Internet Protocol (VOIP) technologies provide packet based voice replacements for traditional telephony. Many novel approaches are possible to initiate calls, such as click-to-call on web sites (used for help desk coverage, among other things). VOIP can provide the same functions—conferencing, long distance, etc. as traditional voice telephony.
In conventional Internet “chat” environments, text conversations via computing devices are held in a semi-synchronous fashion. The chat environment is a chat room, e.g., a Web site, part of a Web site, or part of an online service such as America Online, that provides a venue for users with a common interest to communicate in real time. Unlike forums and discussion groups, chat services have the capacity for interactive messaging and do not require users to have any special software. Internet Relay Chat, which is a system for chatting that involves a set of rules and conventions, does require client/server software, which is capable of being downloaded from the Internet. Chat room users register for a chat room, choose a user identification and password, and log into that particular room. Inside the chat room, generally there is a list of the people currently online, each of whom also are alerted that another person has entered the chat room. To chat, users type a message into a text box and the message is virtually immediately rendered visible in a larger display area so that other users may now respond.
FIG. 1 illustrates a conventional chat system 100. In the chat system 100 depicted in FIG. 1, elements 110 and 140 represent chat client devices physically embodied as a server, a personal computer (PC), a personal digital assistant (PDA), a cellphone or other like computing device. Examples of capable non-personal computer devices include Blackberry devices (available at www.blackberry.com) and AOL which provides Instant Messaging (IM) service for cellphones (http://mymobile.aol.com/portal/im/index.html). Elements 110 and 140 need not represent equivalent devices (e.g., need not both be personal computers), as long as each is capable of providing the infrastructure of a chat client. Generally, devices must have the ability to accept chat input, and to display chat output. Software providing the chat function for devices 110 and 140 may be resident locally, or may be provided as a service by a remote server (not shown). Remote servers providing such software may be different for different clients (e.g., devices 110 and 140 may be served by different remote software servers). As shown in FIG. 1, chats in progress result in text transcripts 120 and 150 that generally provide an indicator of the source of a chat statement (e.g., a nickname for whomever entered the statement), and a textual transcript of the chat statement itself. These are often provided in a window that maintains the sequential nature of the interchange, and provides the visual frame associating all the messages. Elements 110, 140 and a network-based chat service 180 are shown interconnected via a communications network 170 which may comprise a single network, or a set of interconnected networks including links which may be wireless, wireline, broadband and narrowband, and may include the Intemet in general. Chat system 100 additionally include elements 130 and 160 that let chat clients speak to one another via network 170 in a manner much like the experience provided by a telephone call. Elements 130 and 160 particularly enable a client to speak to the other chat client, and hear what the other chat client has said. An example of an audio-capable client device is a personal computer with a microphone and speaker either built in or added on. In addition to the basic textual chat system described above, an audio-capable system requires software for interfacing to the speaker and microphone, encoding and decoding the audio data, a protocol for exchanging the audio data between client devices, and a network 170 with sufficient capacity and bandwidth to send and receive audio data at a rate consistent with spoken conversation. It should be understood that conventional chat systems treat audio and textual data differently. While transcripts 120 and 150 provide a chronological history of the textual messages exchanged in the chat session, they do not include audio data. Audio data is sent from the originating client, and played at the receiving client as it would during a telephone call that was not being recorded.
Through chat embodiments such as Lotus Sametime (an instant messaging and Web conferencing solution for businesses) and AOL Instant Message, individuals may engage in lightweight text interchanges with: 1) minimal overhead to start, 2) minimal expectations as to length of message, persistence, acknowledgement, 3) minimal requirements for rapid response on the part of the recipient. Chat is a conversation, but not a real time conversation (i.e., not synchronous). The sender expects a response, but not necessarily right away. However, unlike e-mail and voicemail, there's an expected thread of continuity between interchanges, presented visually with the ability to display the whole of the interchanges within one chat window per conversation. Such chats may generally be held concurrently, allowing an individual to communicate with many people at once on different topics.
Current e-mail systems now enable the addition of voice elements. For example, audio file formats such as *.wav which are digital audio captured in a file, may now be appended as an attachment to e-mail. It is well known in the art that one can attach audio files to e-mail messages, which may subsequently be played by the recipient at his location. A unified messaging system (e.g., see http://www.iec.org/online/tutorials/unified_mess/) uses this kind of communication to move voice mails around in a fully asynchronous manner. The “Notes Buddy” tool for Lotus Notes™ is an exemplary embodiment that integrates instant messaging (chats) and buddy status with e-mail to produce a single messaging tool. With notes buddy, one can use voice to input to a Notes e-mail which is sent to recipient and appears as a *.wav file attachment to a regular email. Notes buddy also allows a user to play out his/her regular e-mail via text to speech conversion. It is noted that this program provides Lotus Sametime status in conjunction with the mail. Generally, however, an e-mail is sent and received without knowledge of the current availability or willingness of the other party to attend to the e-mail.
AOL, MSN and Lotus Sametime provide the ability to conduct synchronous voice communications. These are fully synchronous “open mike” applications and do not allow any voice exchange that is not synchronous. These applications provide two parallel communications methods—one for text chat and one for synchronous voice. They do not provide semi-synchronous voice, nor the ability to store the voice utterances.
Thus, in sum, today's telephone communication paradigm requires a connected circuit, a call-flow path of call request (dial), call setup, call accept (on the receiver side), cut through and conversation. When one party hangs up the call is terminated. While VOIP does not require a circuit, calls made with VOIP follow the same stringent paradigm, and imply a dedicated listener. While VOIP is now generally used as a replacement for voice telephony, it would be highly desirable to enable means for voice communications that does not require a dedicated listener. Further, while e-mail communications permit audio file attachments enabling asynchronous transmission of voice, it does not allow conversational use of voice on demand. It would thus be highly desirable to provide a means for adding voice on demand elements to data communication systems.
As text chat is very much a hands on, eyes on communication method that does not allow for the ready capture of nuance as does voice. It would further be desirable to provide a “hands off”, “eyes off” version of chat that includes the provision of means for capturing and transmitting nuance as enabled with voice communications.